PMBOK特集

第二部
PMBOK入門

PMBOKとは

本特集の第一部では、システム開発における「デスマーチ」を回避するために、プロジェクトの計画や実行管理の重要性を論じた。第二部では、プロジェクトを計画したり実行管理したりするための知識体系であるPMBOKを解説する。

第一部で述べたとおりPMBOKという名称は、Project Management Body Of Knowledgeのそれぞれ頭文字をとった略称のことである。「プロジェクトマネジメント知識体系」という訳語が当てられるが、日本でもPMBOK（ピンボック）と呼ぶことが多い。その名称が示すとおりPMBOKとは、プロジェクトを成功させるのに効果的であると認められた知識・スキルを体系化したもののことである。

PMBOKを提唱しているのは、米国のプロジェクトマネジメント協会（Project Management Institute, PMI）である。PMIは、プロジェクトマネジメントの知識体系のガイドラインを発行している。ガイドラインの最新版は、2004年に発行された『PMBOKガイド　第3版』である。

PMBOKとPMBOKガイドの違いだが、抽象的な概念としてのプロジェクトマネジメントの知識体系をPMBOKと呼び、その具体的な指針をまとめたものをPMBOKガイドと呼ぶ。一般にPMBOKガイドのことを指して「PMBOK」と呼ぶことが多い。本稿でもPMBOKガイドのことをPMBOKと呼ぶことにする。
ところでPMBOKの解説の順序は、プロジェクトの実行順序とおりでないところがある。そのため、知りたい内容が各所に散在していて概要をつかみにくいことがある。

さらにPMBOKは、システム開発のプロジェクトに特化した知識体系ではない。超高層ビルの建設プロジェクトや金融商品の開発プロジェクトや音楽イベントの企画プロジェクトなど、あらゆる業界のプロジェクトマネジメントに適用できるように策定されている。そのためシステム開発者にとって、PMBOKは解説が一般的すぎて、開発業務へどのように適用したらよいのか、分かりにくいことがある。

以下に、PMBOKの概要を解説する。さらに、PMBOKをシステム開発に適用する上でのヒントを解説する。これからPMBOKを学習しようと考えている読者の一助にしていただきたい。

時間軸に沿って体系化する-「プロセス群」と「プロセス」

プロジェクトをマネジメントするにあたり、特定の成果を生み出す一連の活動のことを、PMBOKではプロセスと呼ぶ。PMBOKでは、44のプロセスを定義している。さらにPMBOKでは、44のプロセスを5つのプロセス群に分類している。

PMBOKを概観するために、5つのプロセス群から取り上げることにしよう。

5つのプロセス群とは、44のプロセスを以下のように分類したものである。

■ 立上げプロセス群

プロジェクトを定義し、認可するプロセスの集合。

■　計画プロセス群

プロジェクトの目標を定め、目標を達成するための一連の活動を計画するプロセスの集合。

■　実行プロセス群

プロジェクトマネジメント計画を実行するために、人や他の資源を統合するプロセスの集合。実行途中で生じた変更によって、実行プロセス群から計画プロセス群へフィードバックが生じるので、図2-1では実行プロセス群と計画プロセス群は、双方向の矢印で結ばれている。

■　監視コントロール・プロセス群

プロジェクトマネジメント計画との差異を識別するために進捗を監視し、差異がある場合に是正処置を実施するプロセスの集合。監視と是正処置によって、他のプロセス群へフィードバックが生じるので、図2-1において監視コントロール・プロセス群と他のプロセス群は、双方向の矢印で結ばれている。

■　終結プロセス群

プロジェクトの成果物を正式に受け入れ、プロジェクトを公式に終了するプロセスの集合。

5つのプロセス群は、プロセスを時間の座標軸に沿って分類したものと言い換えてもよい。すなわち、立ち上げプロセス群の各プロセスを実施して、プロジェクト開始を承認する。次に計画プロセス群の各プロセスを実施して、計画を詳細に練る。実行プロセス群の各プロセスを実施して、計画とおりにプロジェクトを進める。最後に終結プロジェクトの各プロセスを実施して、プロジェクトをクローズする。監視プロセス群の各プロセスは、プロジェクトの立ち上げから終結までを監視するために実施する。

前述のとおりPMBOKでは、5つのプロセス群の下に44のプロセスを定義している。図2-2に、44のプロセスがどのように5つに分類されているかを示す。

PMBOK初心者が図2-2をはじめて見たら、たくさんのプロセスがあることに圧倒されるかもしれない。しかし以下に述べる学習のコツをつかめば、心配無用である。
まず、読者が参加したことがあるプロジェクトの、立ち上げから終結までを思い起こしていただきたい。規模の大きいプロジェクトや、評価の高いプロジェクトマネージャが取り仕切ったプロジェクトであれば、なお良い。

次に図2-2を詳細に見て、読者が参加したプロジェクトをマネジメントするために、どんなプロセスが実施されたか、どんなプロセスを実施すれば良かったのかを考えて欲しい。こうした仕方で44のプロセスを眺めてみると、PMBOKではプロジェクトをマネジメントするためのプロセスが、時間の座標軸に沿って過不足なく整理されていることが理解できるだろう。

マネジメント対象ごとに体系化する-9つの「知識エリア」

旧来から言われていることだが、成功プロジェクトとは、コストを予算の範囲内に収めたり、成果物の品質を顧客が満足するまで高めたり、納期とおりに成果物を完成させたりしたプロジェクトのことである。したがってプロジェクトマネジメントの対象分野として、コストや品質やスケジュールの３つは特に重要である。

さらにこの３つの分野を適切にマネジメントするためには、人的資源をマネジメントして必要なスキルをもった要員を必要な数だけ投入したり、リスクをマネジメントして不測の事態が出現しても致命的な打撃を受けないようにしたりするなど、もっと広範囲の分野をマネジメントの対象にする必要がある。

PMBOKでは、マネジメントの対象として9つの分野を識別している。そして44のプロセスは、これら9つのマネジメント対象に再分類されている。PMBOKでは、9つの対象のことことを知識エリアと呼んでいる。

つまりPMBOKでは、5つのプロセス群によって時間の座標軸に沿ってプロジェクトマネジメントの知識を体系化するだけでなく、9つの知識エリアによってマネジメント対象の座標軸に沿ってもプロジェクトマネジメントの知識を体系している。

以下に9つの知識エリアを列挙する。

1. ①プロジェクト統合マネジメント
2. ②プロジェクト・スコープ・マネジメント
3. ③プロジェクト・タイム・マネジメント
4. ④プロジェクト・コスト・マネジメント
5. ⑤プロジェクト品質マネジメント
6. ⑥プロジェクト人的資源マネジメント
7. ⑦プロジェクト・コミュニケーション・マネジメント
8. ⑧プロジェクト・リスク・マネジメント
9. ⑨プロジェクト調達マネジメント

以下に９つの知識エリアを解説する。

①プロジェクト統合マネジメント

プロジェクトを成功させるためには、コストと品質と納期の目標を期待とおりに達成することが必要である。しかしその三者はトレードオフの関係にある。たとえば、たくさん人をかければ納期を守れるが、予算オーバーになってコスト面で失敗プロジェクトになる。設計や製造にじっくり日数をかければ顧客満足度の高い成果物を納品できるが、納期を守れなくなってやはりスケジュール面で失敗プロジェクトになる。
すべてのマネジメント対象分野をバランスよくマネジメントすることが必要だが、そのためのプロセスをまとめた知識エリアが、プロジェクト統合マネジメントである。図2-3に、44のプロセスの中、どのプロセスがプロジェクト統合マネジメントの知識エリアに分類されるのかを示した。

図2-3　プロジェクト統合マネジメントに含まれるプロセス

②プロジェクト・スコープ・マネジメント
プロジェクトで、何をするのか、何をしないのか、という作業範囲のことを、プロジェクト・スコープ（以下、スコープと略す）と呼ぶ。スコープがあいまいなままスタートしたシステム開発プロジェクトは、やがて顧客との大きなトラブルに発展することが多い。また、プロジェクトの途中でスコープを変更する必要が生じた場合でも、変更を承認したり変更を反映したりするための仕組みが機能していないと、コスト面やスケジュール面で泥沼状態になることが多い。
スコープを定義したり検証したりコントロールしたりするプロセスは、プロジェクト・スコープ・マネジメントの知識エリアに分類される。

図2-4 プロジェクト・スコープ・マネジメントに含まれるプロセス

③プロジェクト・タイム・マネジメント
プロジェクトの成否を評価する特に重要な条件の一つは、納期を守れたことである。納期を守れるスケジュールを立てて、それに従ってゆくためのプロセスは、プロジェクト・タイム・マネジメントの知識エリアに分類される。

図2-5　プロジェクト・タイム・マネジメントに含まれるプロセス

④プロジェクト・コスト・マネジメント
プロジェクトの成否を評価する、納期以外の重要な条件は、予算とおりに終わったかどうかである。予算を立て、予算の消化状況を監視し、予算内にプロジェクトを完了させるためのプロセスは、プロジェクト・コスト・マネジメントの知識エリアに分類される。

図2-6　プロジェクト・コスト・マネジメントに含まれるプロセス

⑤プロジェクト品質マネジメント
納期・コストに加えて、プロジェクトの成否を判断するもう一つの重要な条件は品質である。ソフトウェアの品質は、バグをテスト工程で発見することによって達成されるものではなく、システム開発の計画・設計・製造の各工程で作りこむものである。各工程でどのように品質を作りこんでゆけるかをマネジメントするプロセスは、プロジェクト品質マネジメントという知識エリアに分類される。

図2-7　プロジェクト品質マネジメントに含まれるプロセス

⑥プロジェクト人的資源マネジメント
限られた予算・日数の中で期待された品質を達成するためには、必要なときに必要なスキルを持った要員を、必要な数だけ投入する必要がある。それを実践するためのプロセスは、プロジェクト人的資源マネジメントの知識エリアに分類されている。

図2-8　プロジェクト人的資源マネジメントに含まれるプロセス

⑦プロジェクト・コミュニケーション・マネジメント
プロジェクトと利害関係にある人や組織のことを、ステークホルダーと呼ぶ。たとえば顧客やプロジェクトメンバーがそうである。ステークホルダーと良いコミュニケーションを図ることは、プロジェクトの成否に大きな影響を及ぼす。ステークホルダーに、どのような情報をどのタイミングで提供するのかをマネジメントするプロセスは、プロジェクト・コミュニケーション・マネジメントという知識エリアに分類される。

図2-9　プロジェクト・コミュニケーション・マネジメントに含まれるプロセス

⑧プロジェクト・リスク・マネジメント
プロジェクトに、プラスまたはマイナスの影響を与える不確実要素のことを、リスクと呼ぶ。事前にリスクを想定・評価して対応するプロセスは、プロジェクト・リスク・マネジメントの知識エリアに分類される。

図2-10　プロジェクト・リスク・マネジメントに含まれるプロセス

⑨プロジェクト調達マネジメント
プロジェクト・チーム・メンバーだけでは、中間成果物や最終成果物を作成できない場合、パッケージソフトを調達したり、開発工程の一部を外注したりすることになる。このような、プロジェクト・チームの外から製品やサービスを調達するためのプロセスは、プロジェクト調達マネジメントの知識エリアに分類される。

図2-11　プロジェクト調達マネジメント

PMBOKをシステム開発に適用する

PMBOKは、あらゆる業種向けに策定されたものなので、システム開発者が業務に適用する場合、PMBOKをカスタマイズする必要がある。
PMBOKをカスタマイズするポイントの一つは、システム開発の工程の流れを、PMBOKのプロセス群/プロセスへどのようにはめ込むかである。これをウォーターフォールの開発モデルを例にして考えよう。ご存知のとおりウォーターフォールモデルとは、要件定義、設計、製造、テストなどの各工程が順番に実施される開発モデルのことである。
PMBOKでは、プロジェクトの下位概念として、フェーズという概念がある。要するに、特定の中間成果物を完成・承認する工程をフェーズと呼び、プロジェクトをフェーズに分割して、プロジェクトの運営や管理を容易にする、という考えである。PMBOKでは、これらのフェーズが連なることにより、プロジェクト・ライフサイクルが構成されると考える。そこで、PMBOKにおけるフェーズの概念の階層に、ウォーターフォールモデルの開発工程をはめ込むことができる（図2-12）。

図2-12　PMBOKのフェーズの概念とウォーターフォールモデルの開発工程

プロジェクトの規模が大きくなると、初期の計画フェーズの時点ではスケジュールを詳細まで詰めきれないことがある。その場合、開発フェーズが進むごとに計画を詳細化してゆく。また、特定の開発ベンダーにロックされることを嫌う顧客の場合、開発フェーズ単位で入札を行ない、ベンダー選定を繰り返すことがある。その場合、ベンダーは、開発プロジェクトの一フェーズの中だけで、プロジェクトの立ち上げから終結まで実施する。
PMBOKでは、フェーズの下位概念として、各フェーズの中で5つのプロセス群のサイクルが回るケースも想定している（図2-12）。大規模プロジェクトや開発フェーズ単位で受注するプロジェクトの場合、フェーズ単位でもPMBOKを適用できる。
PMBOKをシステム開発業務にカスタマイズする際の別のポイントは、PMBOKで紹介されているツールや技法を取捨選択することである。
紙面の都合で詳述しなかったが、PMBOKでは、個々のプロセスの詳細説明において、そのプロセスを実施する上で有効と一般的に認められている、ツールや技法を列挙している。すべてのツールや技法を無理に導入しようとするのではなく、プロジェクトの規模やシステム開発固有の特性を考慮して、取捨選択する必要がある。ただし、まだ使用したことにないツールや技法でも、効果がありそうなものは、積極的に導入を検討するとよい。
たとえばPMBOKは、コスト管理の技法としてEVM（Earned Value Management）を紹介している。EVMとは、金額ベースで進捗管理を行なうことによって、成果物の進捗の予定・実績を管理するだけでなく、予算消化の予定・実績も管理する管理手法である。すでにEVMは、システム開発の現場で普及が進んでいる技法だが、本稿の読者が未導入ならば、検討することを勧めたい。

PMBOK導入のメリット

システム開発プロジェクトにPMBOKを導入することには、メリットがいくつもある。その一つは、他業界の成熟したプロジェクト手法をお手本にできることである。
他業界の中には、プロジェクトマネジメントの長い歴史を持っているものが少なくない。たとえば自動車業界は、新車開発プロジェクトの経験を数十年にもわたって積み上げてきている。建築業界のプロジェクトの経験は、人類の建築の歴史と同じだから、数千年のキャリアがある。一方、システム開発業界は、まだ若い業界であるため、システムの開発プロセスが未熟であると繰り返し指摘されてきた。

PMBOKは、建築業界など様々な業界におけるプロジェクトマネジメントのノウハウを体系化したものである。システム開発者がPMBOKを学べば、プロジェクトマネジメントの先達たちから教えを受けることになるのである。

PMBOKを導入する別のメリットは、システム開発の受発注者の双方がプロジェクトマネジメントを語る上で、共通の用語集を持てることである。

PMBOKの認知は内外で進んでおり、プロジェクトマネジメントの知識体系としては、デファクトスタンダードの地位を占めている。今後もさらに多くの企業・団体が、PMBOKに準拠したプロジェクトマネジメント標準を採用することが予想される。

システム開発の受発注者の双方がPMBOKに準拠した開発標準を有している場合、共通の用語としてPMBOKの用語を使用できるので、プロジェクトマネジメント関係のコミュニケーションをスムースに行なえる。

【参考文献】
・広兼　修著、『プロジェクトマネジメント標準　PMBOK入門』、オーム社、平成17年